\documentclass{article}
\usepackage[utf8]{inputenc} % un package
\usepackage[T1]{fontenc}      % un second package
\usepackage[francais]{babel}  % un troisième package
\usepackage{amsmath}
\usepackage{graphicx}

\title{Sécurité Des OS - TDs}
\author{Alexandre Masson}
\date{20 Septembre 2013}

\begin{document}
\maketitle
\newpage
\section{TD1}
\subsection{Les droits d’élévation de privilèges}
\paragraph{Question 1 }
\textbf{ Vous créez une copie /bin/moncat du binaire /bin/cat.
}\\
cp /bin/cat /bin/moncat\\
résultat : ls -al /bin/moncat
-rwsr-xr-x 1 root root 42816 20 spet. 14:11 /bin/moncat
\paragraph{Question 2}
\textbf{Vous positionnez le bit setuid pour ce binaire.}\\
chmod u+s /bin/moncat

\paragraph{Question 3}
\textbf{A partir d un acces avec le compte essai, vous exécutez /bin/moncat /etc/shadow.Commentez le résultat. Est ce problématique d un point de vue sécurité}\\
On récupère avec le compte essai le contenu du fichier /etc/shadow, le bit setuid que nous avons rajouté augmente les permissions de essai au niveau de root, proprietaire du /bin/moncat. Il faut donc utiliser le bit "s" avec précaution, car il peux donner les droit divin à un utilisateur standard, si celui ci utilise un exécutable dont root est le propriétaire. 

\subsection{Les ACL}
\paragraph{Question 1}
\textbf{Création des utilisateurs
}\\
On vois bien les utilisateurs dans le fichier /etc/shadow

\paragraph{Question 2}
\textbf{Créer et monter un FS, donner la propriété à user1}\\
\includegraphics[scale=0.5]{captureQ2ACL.png}\\
On aperçoit à la dernière ligne le nouveau FS

\newpage
\paragraph{Question 3}
\textbf{Sous le compte de user1 créer une arborescence dans le FS}\\
le résultat du ls nous apprend que les fichiers appartiennent à user1 et que seul celui ci a les droit r et w , soit lecture et écriture.\\\\
le resultats du getfacl nous donnes les informations user par user et groupe par groupe des différent accès sur les fichiers.\\
\includegraphics[scale=0.5]{capturegetfaclQ3.png}\\
le dernier ls nous affiche que les droits ont changé, et les + indiquent qu'il existe des permissions supplémentaires définies avec les ACL, on peux les voir avec le GETFACL

\paragraph{Question 4 }\textbf{Testez les accès avec user2}\\
la commande id nous donne les informations des identifiant d'utilisateur et de groupe de user2\\
Les ACL sont prioritaires sur les permissions, donc comme dans les ACL nous avons autorisé l'accès en lecture de f1 par user2, nous pouvons lire f1 sous le compte user2\\
User2 appartient au groupe paire, et le groupe paire à l'acces en lecture sur rep/fic, donc user2 nous permet de lire rep/fic

\paragraph{Question 5}\textbf{Testez l'acces avec user3}\\
nous n'avons pas donné de permissions au groupe impaire sur f1, donc meme si user3 ets dnas le meme groupe que user1, il subit les acl qui donne group:---, donc il n'a pas la permission de lire f1\\

\paragraph{Question 6}\textbf{Modifier les ACL sur f1}\\
pas de question dans cette partie

\paragraph{Question 7}\textbf{accès avec user2}\\
nous avons changé le mask dans la partie précédente,  et nous l'avons forcé à --- , et comme le mask fais un "ET logique" avec les permissions pour déterminer l'accès, il refuse l'accès à f pour user2 , car même si celui-ci possède le droit "r", le masque le restreint.


\subsection{Les capacités}
\paragraph{Question  1}\textbf{Supprimer les élévations de privilèges de ping}\\Nous avons retirer le sticky bit "s" dans le ping, donc l'utilisateur lambda devrait ne plus bénéficier des droit root à l'exécution de ping.

\paragraph{Question 2}\textbf{Utiliser ping à partir du compte guest et root}
Sous le compte guest, le ping nous renvoi une erreur d'exécution, car le guest ne bénificiant pas des droit root, ping ne peux pas ouvrir la socket : Operation non permitted\\
Alors qu'avec le droit de root, tout se passe normalement

\paragraph{Question 3 }\textbf{Modifier les capacités de la commande ping}\\
le getcap /bin/ping ne renvoi rien , car la commande ping n'est pas soumise à des capacités. \\
Après modification des capacité de ping, getcap nous renvoie bien la capacité ajoutée

\paragraph{Question 4}\textbf{Testez à partir du compte guest}\\
le resultats de /sbin/getpcaps nous renvoie : "capabilities for '1683': = ", ce qui nous indique que les capacités pour le processus courant sont nulles, car nous n'avons pas donné de capacités "globales" à guest\\
Comme nous avons autorisé la capacité à  se connecter, il remarche normalement , meme pour guest

\newpage
\section{TD2}
\subsection{Partie 1}
\paragraph{Question 2}
lesz différentes lignes du script dChrootProtect.sh met des 0 au permissions/capacités autorisé pour chroot, toutefois on constate qu'il met aussi des 0 à des opération de deny,
donc les fail du a des deny ne risque pas d'arriver

\paragraph{Question 4} A l'exécution du script break-chroot2, nous nous retrouvons dans la dossier racine "/", et on sors du cadre restreint pour lequel on utilise justement chroot, normalement chroot empeche de sortir d'un espace alloué et empeche de pouvoir aller se balader un peu partout, ici, break-chroot reste dans le bash lancé avec chroot, mais il sors de l'esapce protégé du chrrot et ramene à la racine.

\paragraph{Question 5 }
le script aChrootProtect.sh remet des 1 là ou le script précédent mettait des 0 ,  il remet en place les vérifications de type deny qui vont empecher le break-chroot de fchdir par exemple.

\paragraph{Question 6}
Avec les modifications précédentes, le break-chroot se voit interdit de faire un changedir, car dans l'espace chroot, nous avons mis à 1 le chroot\_deny\_fchdir, donc le break-chroot exécuté dans cet espace ne peut réaliser son opération. Cette fois ci nous ne sortons pas de nos limites.

\newpage	
\subsection{Partie 2}
\paragraph{Question 2}
dmesg nous renvoie tous les printk dus au exécutions des processus , on apercoit aussi les uid et guid des processus, le parent, etc...

\paragraph{Question 4}Nous avons réactivé la sécurité, et donc nous n'avons plus accès à dmesg car dmesg lancé par root la permisson de klogctl, donc il ne peux afficher les messages 

\paragraph{Question 5} Avec la mis en place des controles, ls ne voit plus le dossier, il ne marche donc pas et renvooie no such file or directory

\paragraph{Question 6} dans home nous ne pouvons pas retourner à /etc/grsec, car ce dossier n'est pas visible par root

\paragraph{Question 9} le répertoire /home/alex est \underline{confidentiel} pour les autres

\paragraph{Question 10} définition formelle PIGA : (lesautres, /home/alex).

\paragraph{Question 12}root va dans /home/utilisateur, il peut faire un echo "machaine" >nouveaufichier , qui va ercire un fichier. Mais lors d'un cat nouveaufichier renvoie permission denied

\paragraph{Question 13} le répertoire /home/utilisateur est accessible en écriture pour root, mais pas en lecture

\paragraph{Question 14} définition formelle : (root,/home/alex) lecture

\paragraph{Question 16} root fais un cd /home/alex, il peut ensuite faire un cat monfile, mais recoit permission denied pour mkdir, echo "something" >monfile, etc..

\paragraph{Question 17} le dossier /home/alex est accessible uniquement en lecture pour root

\paragraph{Question 18}
formelle : (root, /home/alex) ecriture,création, suppression

\section{TD3}
\subsection{Partie 1}
\paragraph{Question 1} Quel est le contexte associé à 
\begin{itemize}
\item[/etc/shadow] system\_u:object\_r:shadow\_t /etc/shadow
\item[/etc/passwd] system\_u:object\_r:etc\_t /etc/passwd
\item[programme de /bin] la plupart des fichiers ont comme contexte system\_u:object\_r:bin\_t, les autres ont :system\_u:object\_r:nomprogramme\_exec\_t
\item[login] system\_u:object\_r:login\_exec\_t
\end{itemize}

\paragraph{Question 2}
Quel est le contexte associé à 
\begin{itemize}
\item[votre session] id -Z donne staff\_u:staff\_r:staff\_t
\item[les processus noyaux] ps auxZ |grep kernel donne : \\
system\_u:system\_r:kernel\_t      root         2  0.0  0.0      0     0 ?        SN   16:08   0:00 [ksoftirqd/0]\\
system\_u:system\_r:kernel\_t      root         3  0.0  0.0      0     0 ?        S<   16:08   0:00 [events/0]\\
system\_u:system\_r:kernel\_t      root         4  0.0  0.0      0     0 ?        S<   16:08   0:00 [khelper]\\
system\_u:system\_r:kernel\_t      root         5  0.0  0.0      0     0 ?        S<   16:08   0:00 [kthread]\\
system\_u:system\_r:kernel\_t      root        56  0.0  0.0      0     0 ?        S<   16:08   0:00 [kblockd/0]\\
system\_u:system\_r:kernel\_t      root        57  0.0  0.0      0     0 ?        S<   16:08   0:00 [kacpid]\\
system\_u:system\_r:kernel\_t      root        96  0.0  0.0      0     0 ?        S<   16:08   0:00 [ata/0]\\
system\_u:system\_r:kernel\_t      root        97  0.0  0.0      0     0 ?        S<   16:08   0:00 [ata\_aux]\\
system\_u:system\_r:kernel\_t      root        98  0.0  0.0      0     0 ?        S<   16:08   0:00 [ksuspend\_usbd]\\
system\_u:system\_r:kernel\_t      root       101  0.0  0.0      0     0 ?        S<   16:08   0:00 [khubd]\\
system\_u:system\_r:kernel\_t      root       103  0.0  0.0      0     0 ?        S<   16:08   0:00 [kseriod]\\
system\_u:system\_r:kernel\_t      root       124  0.0  0.0      0     0 ?        S    16:08   0:00 [pdflush]\\
system\_u:system\_r:kernel\_t      root       125  0.0  0.0      0     0 ?        S    16:08   0:00 [pdflush]\\
system\_u:system\_r:kernel\_t      root       126  0.0  0.0      0     0 ?        S<   16:08   0:00 [kswapd0]\\
system\_u:system\_r:kernel\_t      root       127  0.0  0.0      0     0 ?        S<   16:08   0:00 [aio/0]\\
system\_u:system\_r:kernel\_t      root       744  0.0  0.0      0     0 ?        S<   16:08   0:00 [scsi\_eh\_0]\\
system\_u:system\_r:kernel\_t      root       773  0.0  0.0      0     0 ?        S<   16:08   0:00 [kpsmoused]\\
system\_u:system\_r:kernel\_t      root       782  0.0  0.0      0     0 ?        S<   16:08   0:00 [kjournald]\\
system\_u:system\_r:kernel\_t      root      4707  0.0  0.0      0     0 ?        S<   16:09   0:00 [kauditd]\\

\item[le processus syslog-ng] ps auxZ | grep syslog-ng donne :\\system\_u:system\_r:syslogd\_t     root      2332  0.0  0.0   3520   784 ?        Ss   16:09   0:00 /usr/sbin/syslog-ng

\item[le processus login] ps auxZ | grep login donne: rien on ne le voit pas
\end{itemize}

\paragraph{Question 3}
le contexte de session root est : root\_u:staff\_r:staff\_t

\paragraph{Question 8}
le problème de changement de transition se pose, car on pars de bash\_t , et on a besoin de initrc\_t, le changemnt de contexte est non défini, alors qu'en partant de run\_init, on pars du context init, et là la transition vers initrc\_t est autorisée.S

\paragraph{Question 11}
le nouveau context de test est celui du staff  : staff\_u:staff\_r:staff\_t

\subsection{Partie 2}
\paragraph{Question 12}
le module mozilla est composé de 3 fichiers : mozilla.fc, mozilla.te, et mozilla.if
\paragraph{Question 13}
À quoi correspond chaque fichier : 
\begin{itemize}
\item[.fc] déclaration des contextes objets, déclaration des associations fichier <-> contexte objet
\item[.te] déclaration déclaration des règles du module TE
\begin{itemize}
\item nom de module et version
\item Déclaration des rôles types sujets et objets
\item Déclaration des règles de controle
\end{itemize}
\item[.if] Déclaration des règles pour les autres modules
\begin{itemize}
\item Règles dynamiques pour l'interaction avec les autres modules
\item Règles génériques : utilisation de macros et de variables
\end{itemize}
\end{itemize}

\paragraph{Question 14}
le contexte associé à firefox est  :\\
system\_u:object\_r:mozilla\_exec\_t /usr/lib/mozilla-firefox/firefox-bin \\
(donné par ps auxZ |grep firefox)\\
\\

Pour le fichier personnels de firefox  : ls -Z ~.mozilla/firefox :  
root:object\_r:sysadm\_mozilla\_home\_dir\_t pluginreg.dat \\ 
root:object\_r:sysadm\_mozilla\_home\_dir\_t vll9nq57.default\\
root:object\_r:sysadm\_mozilla\_home\_dir\_t profiles.ini

\paragraph{Question 15}
le contexte associé à claws-mail : claws-mail(`root:staff\_r:staff\_t')\\
et ses fichiers personnels : 
root:object\_r:sysadm\_home\_dir\_t accountrc
root:object\_r:sysadm\_home\_dir\_t accountrc.tmpl
root:object\_r:sysadm\_home\_dir\_t addrbook
root:object\_r:sysadm\_home\_dir\_t claws.log
root:object\_r:sysadm\_home\_dir\_t filtering.log
root:object\_r:sysadm\_home\_dir\_t folderlist.xml
root:object\_r:sysadm\_home\_dir\_t folderlist.xml.bak
root:object\_r:sysadm\_home\_dir\_t imapcache
root:object\_r:sysadm\_home\_dir\_t mimetmp
root:object\_r:sysadm\_home\_dir\_t newscache
root:object\_r:sysadm\_home\_dir\_t tagsdb
root:object\_r:sysadm\_home\_dir\_t tmp
root:object\_r:sysadm\_home\_dir\_t toolbar\_main.xml
root:object\_r:sysadm\_home\_dir\_t uidl

\paragraph{Question 16}
les dossier personnel ./dir appartiennent à l'utilisateur root mais en role sysadm\_r, alors que quand on se log, on est en role staff\_r, donc on ne peut pas connaître les contextes des fichiers personnels
\end{document}
